home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc / Developer Documentation / Human Interface / Human Interface Q & A / HI Q& A #11 < prev    next >
Encoding:
Text File  |  1996-04-26  |  10.7 KB  |  218 lines  |  [ttro/ttxt]
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16. Q&A #11
  17. Viewers Versus Editors, and Some Clarifications
  18.  
  19. By the Apple Computer OpenDoc Human Interface Team
  20.  
  21. As published in the March 1996 Apple Directions
  22.  
  23. The OpenDoc human interface team frequently receives questions about OpenDoc
  24. that we need to answer in a public forum to help our partners' OpenDoc
  25. development efforts. We think you should know about the topics these
  26. questions address.
  27.  
  28. But first, a correction. There was an error in our answer to the second
  29. question in last January's "OpenDoc Human Interface FAQs" article. Since the
  30. OpenDoc shell implements Close, Save, and Save As, the root part is never
  31. given a chance to handle these events. This error in the article shouldn't
  32. affect how you implement your editors, however.
  33.  
  34. And now to this month's questions.
  35.  
  36. Q: Why do we have part viewers, how do they work, and what are they supposed
  37. to do? I'm confused about how they differ from part editors.
  38.  
  39. A: Viewers are a boon to users who don't have the editor required to
  40. manipulate some particular content. The purpose of a viewer is to allow
  41. users to preserve the appearance, at the highest possible fidelity, of the
  42. content in a document. An editor, of course, preserves this fidelity and
  43. gives the user the ability to manipulate the content. A viewer is not
  44. intended as a mechanism to "lock" a document and prevent it from being
  45. changed; instead, the viewer is one mechanism for enabling the user to see
  46. the content when the user doesn't own the appropriate part editor.
  47. (Translation--that is, allowing an appropriate part editor to translate and
  48. display the content--is another mechanism, but the content may lose
  49. something in translation.)
  50.  
  51. You may, in fact, want to provide a part viewer as a promotion for your
  52. product--it's free for the user, it's easy for you to provide once your
  53. editor is market-ready, and it allows users to see what content they could
  54. create if they had your editor.
  55.  
  56. A viewer allows users to see and print all of the content of a document, and
  57. to view existing content in standard formats (for example, QuickTime movies,
  58. QuickDraw 3D objects, and bitmapped graphics). A viewer does not allow users
  59. to make changes that can be saved, but it may allow minor temporary edits,
  60. such as formatting or font changes. While the content that is intrinsic to
  61. the viewer may not be manipulated, any content embedded within a viewer, for
  62. which you have an editor, may be fully manipulated.
  63.  
  64. Because a viewer doesn't have all the functionality of the corresponding
  65. editor, you should simplify your viewer's menus by removing (not just
  66. dimming) the menu items that are exclusive to the editor.
  67.  
  68. Q: I'm making an editor and a viewer for my part. Are there any guidelines
  69. for naming these items?
  70.  
  71. A: Remember that end-users will use stationery pads (in the Stationery
  72. folder) to create new parts. So, first we'll remind you of the guidelines
  73. for stationery names.
  74.  
  75. The name of a stationery pad should indicate its purpose. For example, a
  76. stationery pad that creates a medical form might be named Medical Form. For
  77. stationery pads that have no initial content, use the name of the category
  78. or the product name. For example, you might call a graphics part stationery
  79. pad either Drawing (its category name) or SurfDraw (its product name). Do
  80. not use the word stationery in the name.
  81.  
  82. By the way, many of our sample parts are using incorrect names for their
  83. stationery pads. This error will be fixed in the next release; we're sorry
  84. we missed it this time. For part editors, we suggest you use just the
  85. product name--for example, SurfWriter. Part viewers should have the word
  86. Viewer appended to the name--for example, SurfDraw Viewer. If your current
  87. application uses the term Player, then for consistency, you can continue to
  88. use the term Player, but you should move to using the term Viewer as soon as
  89. possible.
  90.  
  91. Remember that editors and viewers have slightly different icons. Read
  92. Chapter 12 of the OpenDoc Programmer's Guide for details.
  93.  
  94. Q: What happens if I have the editor for content that is embedded in a
  95. viewer?
  96.  
  97. A: In a word, if you have an editor, it will work on its own content,
  98. whether that content is embedded in a viewer or not. Consider the case in
  99. which only a viewer is present for a compound document's container, but the
  100. user has all the necessary editors for the document's embedded content. The
  101. embedded content can be changed, but the container's intrinsic content can
  102. only be viewed.
  103.  
  104. What? A viewer that lets me change things inside it? Here's the distinction:
  105. The viewer only affects its own intrinsic content; any content embedded
  106. within it, for which the user does have the appropriate editor, may be fully
  107. manipulated.
  108.  
  109. Q: What operations should my viewer support?
  110.  
  111. A: You'll find these operations discussed in Chapter 12 of the OpenDoc
  112. Programmer's Guide. Your viewer should be able to read, display, and print
  113. its content. We also recommend that your viewer support selection, so that
  114. users can access Part Info or Link Info on embedded parts or links; this
  115. gives users more flexibility for changing editors for embedded parts. You
  116. also may want to allow users to drag content and parts out of your part, so
  117. that they can copy content to the Finder or to other documents. Remember
  118. that, in general, a single click should always activate the part and not
  119. select it; this guideline still applies when an viewer is being used.
  120.  
  121. Viewers should support all the commands in the Document menu except Insert.
  122. In the Edit menu, viewers should remove the Cut, Paste, Paste As, and Clear
  123. commands. In addition, a viewer should not support drag-and-drop operations
  124. that would modify or remove content. For example, don't allow the user to
  125. select some content and drag it to the Trash. Some viewers now allow this,
  126. but this is a bug. (We forgot to mention this case in the OpenDoc
  127. Programmer's Guide).
  128.  
  129. We'd like to reiterate that a viewer should not be capable of adding,
  130. embedding, or removing content from a part. Only an editor should have those
  131. capabilities. As we said earlier, your viewer should also remove any other
  132. content-editing commands in menus displayed by your editor. If you enable
  133. any editing commands in the menu bar, make sure you notify the user that any
  134. changes made will not be saved.
  135.  
  136. Q: Why can't I paste or drag and drop into a part handled by a viewer?
  137.  
  138. A: With today's application-based viewers (Adobe Acrobat, for example),
  139. you're allowed to change the content of what you're looking at by completely
  140. replacing it. If you did that with OpenDoc viewers, you'd lose any embedded
  141. content. To prevent the loss of data, your viewer would need to follow all
  142. the rules for merging and embedding content. Once you provide this support,
  143. you have an editor (albeit one with limited capabilities) instead of a
  144. viewer.
  145.  
  146. Here's an example you may be familiar with. The PictureViewer part editor
  147. supplied with OpenDoc originally allowed a paste (or drop) of a new picture
  148. into the part; this replaced all the content. Although it appears that this
  149. behavior was popular, it was wrong and, after much debate, Apple changed
  150. PictureViewer so that it could no longer replace the graphics being viewed.
  151.  
  152. You may decide that your viewer will not support embedded content. In this
  153. case, you might think that, since you don't allow other content to be
  154. embedded in your viewer, you can support your viewer changing content
  155. because that would never be destructive--there would never be loss of
  156. embedded content. However, whether you support embedded content or not, we
  157. strongly suggest that all viewers should present a consistent user
  158. experience --namely, that the user can add content to a part using an editor
  159. but not using a viewer.
  160.  
  161. After all, a viewer is a viewer--and not an editor. If you're providing more
  162. functionality to your viewer, then perhaps you're really delivering a
  163. low-level editor and should reconsider how you structure and name your part.
  164.  
  165. Q: I plan to write a simple text editor. I will support plain but not styled
  166. text during drag and paste operations. This means that, if I follow your
  167. previous guidelines (see "OpenDoc Human Interface FAQs" in the October 1995
  168. issue), I will have to display an alert each time content is added to my
  169. part, to inform the user that some formatting or content may be lost. For
  170. repetitive drag or paste operations, it could become really annoying for
  171. users to have to continually dismiss the alert. Is this what you intended?
  172.  
  173. A: We think you've got a very good point, and we have accordingly modified
  174. our guidelines (hey, we're always open to suggestions!). In our October 1995
  175. article, we recommended that part editors display an alert to notify the
  176. user that some data might be lost during a copy operation. When your
  177. question came in, we thought about this situation some more and agreed that
  178. in some cases it could be very irritating to the user to have the alert
  179. displayed repeatedly. Therefore, we still believe in principle that
  180. notifying the user of loss of data is a good idea, but that consistent
  181. notification is problematic in a number of ways.
  182.  
  183. Because of this, there are times when this guideline may not apply to you;
  184. please use your best judgment. And the situation may not be that
  185. critical--after all, most of today's applications do not alert the user when
  186. data or formatting is lost, and users seem to easily recognize when they
  187. have lost data or formatting. With the multiple-level "undo" support in
  188. OpenDoc, the user can undo a drop or paste operation to safely revert to the
  189. state of the document before the attempted drop or paste operation.
  190.  
  191. So, we need to clarify our previous guideline. Here's what we should have
  192. said:
  193.  
  194. 1. If your editor chooses a part kind for a paste or drop operation, it must
  195. support it completely. For example, the part editor that is the destination
  196. for a paste or drop should not strip embedded content or links out of the
  197. data format. If you can't preserve the fidelity of the paste or drop, then
  198. you must choose a lower fidelity part kind. If there is no available lower
  199. fidelity part kind, then you must judge whether to accept the paste or drop
  200. and display an alert, or whether to reject the paste or drop.
  201.  
  202. 2. Completely support the undo feature so that, if data is lost in a paste
  203. or drop operation, the user can undo the operation and recover the state of
  204. the document before the paste or drop operation.
  205.  
  206. 3. We strongly recommend that your part editor support embedding. That way,
  207. if it can't do anything else, your editor will be able to accept the content
  208. as embedded content.
  209.  
  210. So, we've been enlightened. The suggestion in our previous FAQ of always
  211. notifying the user through an alert is certainly not the correct advice.
  212. It's good general advice, but your particular situation may prompt you to
  213. follow some alternative.
  214.  
  215. __________________________________________________________
  216.  
  217. Copyright (c) 1996 by Apple Computer, Inc. All Rights Reserved.
  218.